# StrongED$Mode = Document
--------------------------------------------------------------------------------
I would very strongly recommend possibly supplying Robert Seago's
Director-based bin application !Styx instead of the current bin utility.
I have a (somewhat customised!) version, complete with new icons, which
I would be happy to make available to anyone for comparison.

Harriet Bazley harriet__bazley_freeuk_com

--------------------------------------------------------------------------------
I've got : 'ScreenBlank' and 'Hourglass off' in Desktop, along with 'Lose
Caret'.

Also : 'Printer window' and 'Factor' in System along with 'Reset SysFont'.

In lower section of 'Desktop', I have :

  ScreenBlank   =>
  Lose Caret
  Hourglass Off

and in the lower section of 'System', I have :

  Printer Window
  Default SysFont
  My SysFont
  Factor        =>

Good ideas. I would have thought that Reset SysFont would be more of a
desktop thing that a system thing though.

Lenny lenny__argonet_co_uk

--------------------------------------------------------------------------------
For AddSprites users, here's a simple extension to the 'Wimp Sprites'
menu (after 'ROM' and 'RAM') :

  Option "Lock"
     Command Set AddSprites$Control On
  Option "Unlock"
     Command Set AddSprites$Control Off

If these were wrapped up in a RMEnsure for the AddSprites module, then
this could possibly be included in the standard distribution, and only
appear if relevant.

Lenny lenny__argonet_co_uk

Expand this to cover the range of AddSprite options.

--------------------------------------------------------------------------------
|===========================================================================|
| Title:   RunActs
| Author:  Lenny
| Date:    15 Jan 2001
| Purpose: Filetype to application associations menu definitions
|===========================================================================|

Menu "Run Actions"
	Option "GIF" -sub "RunAct GIF"
	Option "JPEG" -sub "RunAct JPEG"
	Option "PNG" -sub "RunAct PNG"
	Option "Sprite" -sub "RunAct Sprite"
	Option "TIFF" -sub "RunAct TIFF"
Dash
	Option "HTML" -sub "RunAct HTML"
Dash
	Option "MIDIFile" -sub "RunAct MIDIFile"
	Option "Wave" -sub "RunAct Wave"
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct GIF"
	Option "!ChangeFSI"
		Command Set Alias$@RunType_695 Run ADFS::Res.$.!SystExts.Image.!ChangeFSI.!Run %%*0
	Option "!Photodesk"
		Command Set Alias$@RunType_695 Run ADFS::Res.$.Apps.Image.!Photodesk.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct JPEG"
	Option "!ChangeFSI"
		Command Set Alias$@RunType_C85 Run ADFS::Res.$.!SystExts.Image.!ChangeFSI.!Run %%*0
	Option "!Photodesk"
		Command Set Alias$@RunType_C85 Run ADFS::Res.$.Apps.Image.!Photodesk.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct PNG"
	Option "!Png2Spr"
		Command Set Alias$@RunType_B60 Run ADFS::Res.$.Utils.FileConvs.Graphic.!Png2Spr.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct Sprite"
	Option "!Paint"
		Command Set Alias$@RunType_FF9 Run Resources:$.Apps.!Paint %%*0
	Option "!Photodesk"
		Command Set Alias$@RunType_FF9 Run ADFS::Res.$.Apps.Image.!Photodesk.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct TIFF"
	Option "!ChangeFSI"
		Command Set Alias$@RunType_FF0 Run ADFS::Res.$.!SystExts.Image.!ChangeFSI.!Run %%*0
	Option "!Photodesk"
		Command Set Alias$@RunType_FF0 Run ADFS::Res.$.Apps.Image.!Photodesk.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct HTML"
	Option "!Bookworm"
		Command Set Alias$@RunType_FAF Run ADFS::Res.$.Apps.Comms.Browsers.Bookworm.!Bookworm.!Run %%*0
	Option "!Fresco"
|		Command Set Alias$@RunType_FAF Run <VTiInternet$Dir>.Apps.Web.!Fresco.!Run %%*0
		Command Set Alias$@RunType_FAF Run ADFS::Res.$.Apps.Comms.!Voyager.Apps.Web.!Fresco.!Run %%*0
	Option "!VoyBrowse"
|		Command Set Alias$@RunType_FAF Run <VTiInternet$Dir>.Apps.Web.!VoyBrowse.!Run -html %%*0
		Command Set Alias$@RunType_FAF Run ADFS::Res.$.Apps.Comms.Browsers.VoyBrowse.!VoyBrowse.!Run -html %%*0
	Option "!WebVoyage"
		Command Set Alias$@RunType_FAF Run ADFS::Res.$.Apps.Comms.Browsers.WebVoyage.!WebVoyage.!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct MIDIFile"
	Option "!MelIDI"
		Command Set Alias$@RunType_FD4 Run ADFS::Res.$.Apps.Music.MelIDI.!MelIDI.!Run %%*0
	Option "!MidiWorks"
		Command Set Alias$@RunType_FD4 Run ADFS::Res.$.Apps.Music.MIDIWorks.!MidiWorks.!Run %%*0
	Option "!Serenade"
		Command Set Alias$@RunType_FD4 Run ADFS::Res.$.Apps.Music.Midi_Seqs.!Serenade..!Run %%*0
EndMenu

|---------------------------------------------------------------------------|

Menu "runs" "RunAct Wave"
	Option "!PlaySound"
		Command Set Alias$@RunType_FB1 Run ADFS::Res.$.!SystExts.Sound.!PlaySound.!Run %%*0
EndMenu

|===========================================================================|

>> >And I've added a new 'Run actions' menu to Filing. This menu contains
>> >absolute pathnames and so wouldn't be suitable for general release.
>
>> I remember thinking about that. I know that it would be difficult to
>> implement, but it would be fancy if I could get it to work.
>
>I guess to simplify it for the user (and complicate it for the
>programmer) it would need a setup app that listed all the possible apps
>that could claim each filetype, for all the filetypes being considered.
>Then the user could drag in any of those apps to activate that particular
>option. I can describe that more fully if you like - the idea's still
>brewing atm.

Lenny lenny__argonet_co_uk

No need. I thinking along the same lines as well.
But this is something for the future.

--------------------------------------------------------------------------------
Improved support for windows. At the moment Director has good support for
icons and menus, but very little for windows (I bet some of you didn't even
know Director did do windows).

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
To be able to add options to a previously created menus.

--------------------------------------------------------------------------------
To be able to define menu colours for permanent and temporary menus.
Should be able to define the title bar colours as well.

--------------------------------------------------------------------------------
Auto scrolling for menus.

--------------------------------------------------------------------------------
Auto IconSprites or Filer_Boot applications
	1) Never
	2) When building permanent menus
	3) If sprite not present
	4) All the time
And which? IconSprite or Filer_Boot
	1) Filer_Boot
	2) only IconSprite

Holding down CTRL when making an auto menu could Filer_Boot the applications
within.

--------------------------------------------------------------------------------
To be able to run a command when Menu is pressed over a normal text item.

--------------------------------------------------------------------------------
Make path options drag-able

--------------------------------------------------------------------------------
Make menu options click-able.

--------------------------------------------------------------------------------
To change Director to create windows instead of menus. This would allow
greater flexibility for displaying items, overcome the 8 menus limit in RISC
OS and allow menus to persist if 'torn' off. However, this would come at the
cost of increased complexity and would only be implemented if Director's
support for windows was improved (see above).

Define colours of menus above dashed line?

--------------------------------------------------------------------------------
If double menu click then do OldMenu: (ie menu over title bar)

--------------------------------------------------------------------------------
If can add menu click option to menu items.

--------------------------------------------------------------------------------
PathNoUp:?

--------------------------------------------------------------------------------
Should open the MenuMenu over the savebox?

--------------------------------------------------------------------------------
Even files could have sub-menu pointers.

--------------------------------------------------------------------------------
Should allow -path to have a submenu pointer if it is a file -makesub?

--------------------------------------------------------------------------------
-path which doesn't complain if file isn't there.

--------------------------------------------------------------------------------
Make File: so just have a file on a sub menu?

--------------------------------------------------------------------------------
Compile menu commands into a block which is then translated into a menu at
open time. Could then have changing files on menus and and more than one
copy of the menu on the screen at once. Could precompile the menu menus or
even just store the command lines!

--------------------------------------------------------------------------------
Disadvantage: when open a menu with path things on would wibble the disc.
have a -wibble? and it would thrash RMA

--------------------------------------------------------------------------------
Full Info for menus with date and time and size, configurable in time format
and extras for name and size, three for files, directories and applications?
Change in the application.

--------------------------------------------------------------------------------
Make MenuText be a heirachical thing so MenuText MenuText-1 MenuText-2 etc
get set as do MenuText1 MenuText2 etc. Make MenuText be set whenever a
sub-menu as well as a command is transversed for dynamic test menus.

As in: Memoriser, but for MenuText

--------------------------------------------------------------------------------
Have a debug mode where non-existent menus produce errors when you use them.
The same for Windows.

--------------------------------------------------------------------------------
FilerWindow_Describe with path of file to get colours that FilerWindow would
have coloured it. R0 points to path name, [bits][title][bg][fg] in bytes
returned in r0.

--------------------------------------------------------------------------------
Make a Menon converter?

--------------------------------------------------------------------------------
Text window display

--------------------------------------------------------------------------------
Summon menus which are sensitive to the icon in the pinboard?
Pin a menu to the pinboard.

--------------------------------------------------------------------------------
Do we actually need to stop the task if we stated one? (could just call
wimp_initialise and then ignore error)

--------------------------------------------------------------------------------
Double click actions for director icons (along with shift ctrl alt modifiers)

--------------------------------------------------------------------------------
Uses the ideas from StrongED eg
  (StrongED File Menu   All tasks   FFFFFFBF)
  Clicking menu at left edge of screen opens a menu
  At bottom edge of screen = F12
  Double click hold does load rather than run
    - theres a module that already does that:
      http://www.simplypeachy.co.uk/othersoftware/downloads/doubletake.zip
    - also Larger does it as well.

--------------------------------------------------------------------------------
Try using Wimp_PlotIcon for the director icons or drawing the icons by myself
anyway to get rid of flicker

--------------------------------------------------------------------------------
Make an update time period for time icons

--------------------------------------------------------------------------------
From: Simon Hatliff simh__dcs_ed_ac_uk

2. There should also be an option to suppress icons in the entire path
   menu, since often a menu is created of lots of applications, all
   which have no icons defined so things look a little messy.

3. Finally, I think there should be an option to stop scanning at
   applications, ie don't have a submenu off applications. Again this
   looks neater with a directory full of applications, whose
   directories will probably not need to be examined.

I think these options should be local to each path item so that a
mixture can be used.

--------------------------------------------------------------------------------
If menus overlap then move the menu to the left to stop it.

--------------------------------------------------------------------------------
Re-run dynamic menus on adjust?

--------------------------------------------------------------------------------
Pin director icons to the pinboard.

--------------------------------------------------------------------------------
Should change the rest of the cases to use EXIT_ERR or UNSTACK_ERR where they
are returning r0 which is not saved.

--------------------------------------------------------------------------------
Change error defining macro to have an option to do an unstack and return
instead of a branch over the error code.

--------------------------------------------------------------------------------
Director doesn't read all the entries in a path with multiple entries. Extend
to director can do this, or add an extension so that |M separated entries in
the -path string (maybe) get con-catenated in one directory (maybe with a
Dash between them?)

--------------------------------------------------------------------------------
Add interactive help to Director

--------------------------------------------------------------------------------
Name of the parent in the memoriser, optional number of path items as an
extra parameter.

--------------------------------------------------------------------------------
AddToMenu <menu name>
	Option ".."
		Command ...
So we could have a in use memoriser, called useful?

--------------------------------------------------------------------------------
Factor out the getting the task handle from a window handle routine (in Task
and Filter)

--------------------------------------------------------------------------------
Factor out all the list handling routines. Need to make sure the name is in
a constant place.

--------------------------------------------------------------------------------
Make the path checking in director more bullet proof so if we do have a file
name with & or $ in it then it won't go wrong (could check for a . or
end of string after it.

--------------------------------------------------------------------------------
> Auto-scrolling menus. The only way I could find to do this was to put
> mouse clicks directly into the mouse buffer for clicks on the scroll
> buttons/bars of a menu-window.

I like the scrolling menus in TreeMenu a lot. I have looked at doing this
and I know of two programs which do, one is called KeyMouse and the other is
TreeMenu.

KeyMouse does it by inserting mouse clicks into the mouse buffer also. The
main reason why I haven't added it is though lack of time, but if you were to
send me the source code of how you did it (in C I think) in return for an
enormous credit in the documentation :-) it would help me along enormously.

I'd also like to investigate the possibility of a generic menu scroller.

--------------------------------------------------------------------------------
> I'm pleased to see that you can use -nosprite on -path options. This
> makes the menu look a lot neater. Now all we need is a -noicons option or
> similar to stop the icons appearing in the path menus, because sometimes
> these menus look messy (esp. in LoRes modes)...

--------------------------------------------------------------------------------
Do path segments automatically as well? If there is only one segment in a path
then add it directly rather that in a sub-menu first.

--------------------------------------------------------------------------------
> (1) TreeMenu does it's own sorting of the directory menus rather than
> relying on the FS. This has two useful side effects.
>
>  (a) You can have different sort orders (eg I have everything sorted by
>  type, sorting alphabetically leaves me a little confused), TreeMenu gives
>  you the choice of explicit name,type,size,date or according to the Filer
>  CMOS bits.
>
>  (b) It works with LongFilenames (currently long names appear near the top
>  according to their 'real' name).
>
> (2) I couldn't find a function to expand a path into a directory tree.
>  eg make C$Path into a menu with the different path elements given a
>  branch each. So I wrote one (attached), use as you see fit.

--------------------------------------------------------------------------------
directorfilter blob * "Command:ProcessKeys F12" -icon IconBar -select

--------------------------------------------------------------------------------
Make a -dragto for DirectorFilter another qualifier like -adjust -select etc.
Could do save to root directory and pin filter.

-dragfrom? filter as well

--------------------------------------------------------------------------------
make Director's menus produce help telling the user what they would do when
clicked on (give the text of the command or note which menu would be opened)
and that would be a useful debugging tool also. I'll see how difficult it
would be to add a help string to each menu item.

--------------------------------------------------------------------------------
Make keys alterable after menu is created.

Director_Hotkey <menu_name> <key> [<option text>]
Director_Hotkey <menu_name> "" [<option text>]

To turn off

--------------------------------------------------------------------------------
> I have couple of questions and possibly a bug report. Firstly, is Obey$Dir
> set up when a file is 'DirectorObey'ed? If it isn't, perhaps it should be?
> If not, it might be better to create a 'DirectorObey$Dir' variable instead.

No, yes and maybe :-)

--------------------------------------------------------------------------------
> I would use the time display, but can't stand the flickery update. Could
> you have the option to update only when the format requires it (I only
> want hh:mm display)? I think I could just about put up with flicker once
> a minute, or perhaps you could even Vsync once a minute to avoid flicker.

This has been driving me nuts too. I don't think updating the icon in a non
flick free way is possible unless I make a sprite icon (no text). I did at
one time put the vsync in which does cure it at the cost of 1% CPU time!


Make an option for DirectorFilter which filers all clicks on filing system
filers. With that then we can make the adjust click on filers configurable
and also add other features (such as SHIFT adjust for a free space display).

--------------------------------------------------------------------------------
> Can you include drag 'n' drop-able files from the path menu's ASAP ?
> It would make it even better for wading through my clipart.

Unfortunately you can't do this from a menu. You can press menu over
a path menu to get the MenuMenu and drag it from there.

Alternatively if you did SHIFT click on a path item it could open the
SaveBox, maybe that would work?

Had an idea about the directory tree menus You were saying that you couldn't
drag files from them but you can intercept menu clicks and maybe shift
clicks. and open a save box.... Can't you intercept a shift-click and start
a file drag straight off without bothering with a save box ?

> > I am planning to add CTRL click on a menu item which will immediately start
> > a drag from the item. This would satisfy your request I think, but it is
> > not terribly easy to remember or teach perhaps.
>
> This option sounds good. In my own program (a menu tree leading to the
> clipart item) I use SHIFT but have a user configurable option as to whether
> SHIFT SELECT runs or saves the item. For the Clipart I have it defaulting to
> SHIFT for run, NOSHIFT for a savebox. The save box default seems to work
> best with younger pupils when they are using clipart in DTP work.
> (I have no objections to CTRL tho !)

OK well this is planned so consider it done :-)
Philip Ludlam: Doesn't happen here. Don't consider it done :-)

--------------------------------------------------------------------------------
Save to director icons..

--------------------------------------------------------------------------------
> When clicking with adjust on some of the menu items, I need the whole menu
> structure to be recalculated (eg changing the tick option on a menu) while it
> is still on the screen. Could you tell me if this is possible with Director?

You mean you want the dynamic menu structures recalculated? Well this isn't
possible with the current version of Director, although you are not the only
person to make that request.

The reason is to do with the fact that in order for a menu tree to remain
open, the address of the menu blocks have to remain the same (a Wimp
limitation). If you recalculate a dynamic menu, you will almost certainly
get a different address for the menu block. This is surmountable, but would
require quite a bit of rw-working.

I have never found it to be a problem though, just a slight annoyance, after
all you can move the pointer back to the arrow in order to re-open the menu.

What you ask might be possible with a Director_ReCalculateMenu command, but
that is getting tricky too (thw whole menu would be re-done). I'll think
about it!

--------------------------------------------------------------------------------
From: Frank Foehl foehlfk__tick_informatik_uni-stuttgart_de

I've noticed one bug:

Option -path |<Bla$Dir>

will only produce an arrow with submenu when Bla$Dir points to a valid
directory at the moment when Director is run. When Bla$Dir is initially
invalid or unset, but is set valid later, you get the directory icon in the
menu, but never the right arrow with submenu (unless -up is used, which I
don't want).

*Please* make the directory menus more configurable - eg one could want
a title bar directory menu *without* up menus (text editor window),
or with *only* up menus (filer window) - the current directory menus look
a bit loaded and produce too much redundant information.

The one thing that I'm missing is directory menus and MenuMenus over the
pinboard - I want to click menu on a directory icon pinned on the pinboard,
and have the corresponding directory menu open at once. Basically this is
possible with the filters, but only for certain pinned files (because you must
provide the icon number), and I can't figure out how to get the corresponding
path.

--------------------------------------------------------------------------------
> An extension to the 'DirectorIcon' command that allows pinning of icons on
> the Pinboard that still act as normal icon bar icons.

I've thought about this in the past. It is not particularly easy to do
without patching the pinboard. Not quite impossible though. As a bodge you
can pin an obey file with a DirectorShowMenu command at the end of it. You
need to double-click the file though.

--------------------------------------------------------------------------------
> Director_ReCalculateMenu (you've already told me about that one ;)

--------------------------------------------------------------------------------
> Right, you asked me about ideas for interfacing windows with menus (like info
> windows). The only way I can see of doing this is as follows:
>
> a '-template <File name of template>' option followed by a '-winhandle <name
> of window>' option. There would have to be some code to actually fetch and
> open the window, prehaps handled by a central window manager?
>
> 2 options may be too much so it could be shortened to '-window
> <template_name.window_name>'
>
> There would need to be some option for the behaviour of the windows eg do
> they stay on the screen until they are crossed off, or do they disappear when
> the mouse is clicked on another part of the desktop?

This would be better as an extended menu command I think, then it would be
obvious whether you wanted it opened as a sub menu or permanently.

How about

"Window:<TemplateFileName> <WindowName> <ProgramToRun>"

With the usual director trick of storing what button you clicked on in a
system variable.

The program would be run after the window was created but before it was
opened in order so it could set up the fields in the window.

Alternatively I could make a new syntax for building up windows equivalent
to the Option and Command. You'd need a decompiler for template files so
you could edit them graphically and then turn them into a series of director
commands which you could then adjust. These could work in the same way as
menus.

Eg

DirectorWindow
  WindowIcon <type> <x> <y> <x-size> <y-size> -selected -grey etc
    Command ....
EndDirectorWindow

--------------------------------------------------------------------------------
> An extension to the 'Tasks' menu could be some kind of central manger that
> lets you quit apps and open their main windows from it. (erk, this is
> beginning to sound like Windoze Task Manger!)

Well the tasks menu was just really a place holder to show it could be done.
I welcome suggestions for things to go off here. Perhaps it could do the
functions of the Switch Menu just showing that applications windows also.

There is no reason why it shouldn't be able to quit applications or send
their icons a click though. Nice idea.

--------------------------------------------------------------------------------
> Why don't you set up a Director directory in ResourcesFS so that the various
> disc-based dynamic menus are loaded much quicker? Having installed the new
> version with the "Switch to Window..." menu the disc accesses are rather
> evident...

I've planned to make that an option for a while, thanks for reminding me.

--------------------------------------------------------------------------------
Configuration option for no sub-menu pointer on applications
and a save box as a sub-menu on files.

--------------------------------------------------------------------------------
Make a Director$ShiftMenuMenu ?

--------------------------------------------------------------------------------
Replace DirectorDo with

setmacro alias$do set alias$_do %*0|M_do|MUnset alias$_do
SetMacro Alias$Do Set Alias$_Do %*0|M_Do|MUnset Alias$_Do

--------------------------------------------------------------------------------
make path appear for filer windows
make window appear on sub?

--------------------------------------------------------------------------------
Sort by date

--------------------------------------------------------------------------------
> I wanted the ability to drag files to drive icons, and downloaded
> OverFiler.

I've seen that too.

> However, it had several nasty flaws, and I deleted it. I then
> wondered whether you could achieve the same effect with Director (just
> the dragging bit (I want to use that for copying uploads to floppies)),
> and came to the conclusion that you need a -dragto option for
> DirectorFilters. Could you add this, or am I being dumb?

Yes this could be added. It wouldn't be particularly easy though...

> Presumably you'd
> add -dragfrom at the same time. Then you could modify the dragging
> behaviour of system icons as well as their menus, and Director would be
> even better than it already is.

This is a nice idea - i'll look into it. However I fear that dragging from
icons that don't have the drag type will be very difficult, and if possible
will require a wimp patch.

--------------------------------------------------------------------------------
time scheduling of external progrs/menus for menus
either once after x seconds
every x seconds
or at xx:xx:xx (do we want this more flexible?)

--------------------------------------------------------------------------------
templates with things in indirected strings

--------------------------------------------------------------------------------
Grant Randall:
Add a filter to drive icons so it can be turned off and made more useful...

--------------------------------------------------------------------------------
Grant Randall:
Is it possible to get up the menu menu directly on the filter over the filer
to eliminate the filer menu completely - special case the filer to put the
path of the icon into the system variable

--------------------------------------------------------------------------------
> I just had an idea for Director after having browsed through the RISC User
> magazine. Could it be possible to create 'floating' icons instead of standard
> (ie. fixed) iconbar icons? The user could put these icons where he wants (eg.
> on the top or right side of the desktop) by dragging them (or defining a
> position in the menu config file) and an option should be available to
> keep them in front or on the back of all the other windows. They will be
> more useful than the iconbar ones (which I never use because are difficult to
> find and my iconbar is already too full!) and will not be completely outside
> Director's aim and structure (unlike windows like 'Blinds' that would be very
> useful but probably need a stand alone program, not a Director's extension).

CMOS settings

--------------------------------------------------------------------------------
Save memory on tasks menu

--------------------------------------------------------------------------------
Make an arrow of text files (and other data files) which puts the first 10
lines into a menu. And give you some options of what to do to it.

Set Director$FileTypeMenu_XXX is a dynamic menu to do this. If not set then
the feature is disabled.

_XXX is default option.

--------------------------------------------------------------------------------
AW Horsley

> More user friendly way (eg via dialogue boxes) of customising the menus

Well this is something that has been on the to do list for a while! The
latest version of Director has the ability to deal with windows which is
half the problem, but I just can't find the time to work on it at the
moment!

> Facility to display quantities other than time / date (free memory, CPU load
> etc) under the icon bar icon.

Yes this is an idea which had been mentioned before. This will work by you
telling Director to use a system variable as the text under an icon. This
will be re-read every second and if it changes it will be updated. This
means that you could then have a code variable which read back the free
memory or a module running which calculated the CPU load.

> Commands to put these under icon bar objects other than Director's own.

This is a bit tricky. Firstly how do you specify which icon you want it
under (some apps have none or many icon bar icons). Secondly this would
involve changing the application workspace of another task. This isn't
impossible but just a bit dangerous.

> Desktop/Tasks menu to be able to stop tasks not just list them

This menu was just a test really, but yes this is a good idea. Other ideas
are grab the tasks memory, send it a click or...

> Ability to view current value of variables such as Mousestep

By this I assume you mean the current mouse step as used in the desktop?
This can be done with a dynamic menu quite easily. A bit of grappling with
OS_Word 21 should see it through.

--------------------------------------------------------------------------------
Robin Moffat

> - Clicking menu at the bottom of the screen bring the icon bar to the
> front (StrongED does this but it would be useful for when StrongED
> isn't loaded)

This could be another filter type I suppose. You can't _quite_ do this with
director as it stands at the moment!

--------------------------------------------------------------------------------
DirectorEditAs <filename> <filetype> <StrongED-mode>
Or should that be <zap-mode> ?
Is <filetype> needed?

Or expand DirectorEdit to: DirectorEdit <filename> [<StrongED-mode>]
Both of these require support from the Editors for this though.

--------------------------------------------------------------------------------
From: Reuben Thomas rrt1001__cam_ac_uk

When using a Director Filter with a particular Command: script, Director
seems to swallow the next mouse click after the one that activates the
filter. This may well be something to do with the script:

If "<Greek$Keyboard>" = "" Then Goto SetGreek
Unset Greek$Keyboard
RMKill InternationalKeyboard
RMReInit InternationalKeyboard
Keyboard UK
Obey
|SetGreek
Set Greek$Keyboard true
RMKill InternationalKeyboard
RMLoad <Obey$Dir>.IntKey
Keyboard Greece

(note: Goto is a Wacky-Talky extension; I don't think it's the problem;
see below).

but doesn't happen if I just run the script from the command line or by
double-clicking.

The Filter command is:

DirectorFilter Keyboards "Impression Publisher"
"Command:/Director:Utils.GreekKey" -icon TitleBar -menu

(all on one line, of course).

--------------------------------------------------------------------------------
SKnott

> The second is to offer you them for distribution with Director if you deem
> them so worthy.

Thank you. I'd certainly like to put SavePIN into the distribution. The
GCC things are interesting too, but perhaps not of so much general interest?

> Seriously it took me a while to get a Wimp Message sent and you might
> like to think of an easy way for Director to send messages to tasks.

Good idea. Alternatively a BASIC library/program rather than a *command
might be helpful?

--------------------------------------------------------------------------------
Perhaps Director should do its mouse stuff (OS_Mouse) on callback?

--------------------------------------------------------------------------------
From: Bernhard Christoph Ludewig Bernhard_Ludewig__stud_uni-hannover_de

Yes, the icons are made by myself (I'm designer,->"The Xperience"), so
there could hardly occur any copyright problems when using them:)
The "clicked" icon shall appear (and only in case it looks nice) when
pressing the mouse on the director icon, replacing it until all menus have
gone again.
ciao,

--------------------------------------------------------------------------------
A thought for director:
is it possible to detect a click on a file icon with Select which is then
continued to be held but then menu is pressed. At the moment this behaves
like a double click, but if it could be filtered away from the filer it
could be used to bring up the menumenumenumenumenu or summat. I thought
you might be able to do:

Set Alias$Filer_Run If "|<Key$Menu>" = "0" Then %Filer_Run %*0 Else Echo %*0

But double-click does not issue Filer_Run...

--------------------------------------------------------------------------------
Suggestion. Many * commands take arguments. So how about

  System => Modules => xxxxxx  => *Commands  =>

bringing up a writable icon with the command in it and space for an
argument.

--------------------------------------------------------------------------------
> Is it possible to perform some action when a file is dragged directly from
> an application's savebox to a Director window? It seems that -dragto
> works only for files dragged from Filer windows. What I'd like is a sort
> of "-saveto <directory>".

I see what you mean. Dragto could be extended to do this. However I'd have
to grapple with that horrible set of wimp messages. Since Director is
written in assembler this is less than pleasant :-)

> It is probably easier than you may think. You just have to listen to
> DATASAVE events and reply with a DATASAVEOK message, filling the name
> field with the name of the destination directory (and setting the your_ref
> and size fields, of course).

--------------------------------------------------------------------------------
do a contents of command which goes through a directory and does Option
-path on all the items it finds.

eg
Everywhere -root <Root$Dir>.AntSuite.Apps.Scripts -file "Option -path <Root$Dir>.AntSuite.Apps.Scripts.%0"

but better!

--------------------------------------------------------------------------------
> A feature that would be useful in Director: the ability to make a menu
> selection from any loaded app.

I could imagine a small basic program to do this which could be launched off
a director menu.

--------------------------------------------------------------------------------
On Fri 13 Mar, Graham Crockford wrote:

> I've just switched to using Director (duly removing just about every
> desktop patch I use :-),

That's what I like to hear!

> but one patch I still have to use is Pinfilter, which is a wimp filter
> that responds to a drag to the pinboard from a non-filer window, and sends
> the necessary messages that allow the file to then be saved into a
> temporary directory (this, for example, is where I drop all my web
> downloads for convenience's sake). The file then appears on the pinboard
> as normal, pointing to the saved file.
>
> I'm at a loss how to do this with director... can you help? I quite like
> the idea of a totally neat desktop with just director doing all the
> niggling little patches.

Actually I have to admit that I use PinFilter too!

I could roll it up into Director fairly easily. I'd like to do it in the
most general purpose fashion though!

--------------------------------------------------------------------------------
Filer_OpenDir on adjust click command on an icon bar icon opens a path menu!

AdjustClickFilter should only work on non-director icons?

--------------------------------------------------------------------------------
Extend Director's directory menus.
Provide a switch so that the top option will open the FindDrives menu

--------------------------------------------------------------------------------
Allow the directory menus to return the name of a file or dir as <MenuText>
Then call the Command for the menu option that launched the dir menus.
For example: The code below will add the selected app/dir/file to
Resources:$.Apps
  SYS Option,"Apps -sub <Apps$Dir>"
   SYS Command,"/AddApp <MenuText>"

--------------------------------------------------------------------------------
Edit the File menumenu so that you can bin items from it

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
To write a wimp Director Menu Editor program that would allow easy creation,
modification and deletion of icons, menus and windows.

--------------------------------------------------------------------------------
To make use of the programs in !Director.Apps (only supplied in the 'devel'
archives). Some of them need their user interface modernizing whilst others I
believe are in need of a more substantial update. None of them were ever
released with Director so they will all need testing. If you have ideas for
menus incorporating them, please e-mail me.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
To be able to compile Director under different systems. This can be anything
from a different assembler to trying to get it to compile with the gccsdk
under Linux. Hopefully this will have the effect attracting more developers to
the effort.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
A need to go through the various Director and desktop utilities that are out
there and see if it's possible to incorporate them. I know that I have a
folder containing possibly useful additions to Director which I will go
through to see if they are good/interesting enough to be incorporated. If you
have written one that you want to submit then please contact me. I will ensure
that I have the authors permission before I incorporate anything.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
Technical documentation. I have started a document in Ovation Pro, but it does
need more work done on it.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
To recreate/reverse engineer the assembled utilities that I haven't been
able to find source code for. Alternatives may be used instead but
that depends on licensing conditions. Note: this is essential if a 32-bit
version of Director is to be produced. For your information the
source code that I have managed to find is supplied in the devel archive.
(I still have some pieces to add)

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
For a more long term look at things, 32-bit compatibility is the mains
stumbling block on the horizon. From reports issued by RISC OS Ltd. and
messages from it's employees, it looks like we could possibly get a
32-bit version of RISC OS (aka RISC OS 5) in 2003 - if we believe what they
say.

Both Director and it's support library aren't 32-bit compatible. As the
Director module is programmed ARM code (rather than a language like C) it will
need more than just a recompile to get it to work. All the associated
utilities will also need a thorough going over. All the assembled ones will
need alterations to ensure that they will work without problems under the new
system.

This is likely to be a long and difficult task and so I am looking for
volunteers to help me complete it. Please contact me if you think you
could help. Any work being done in this area is directed to updating AssLib.
This is because that AssLib is the core of Director and also contains the
most 26-bit only code.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
I would like to see a way of controlling directory menus.
In particular being able to switch off revealing the contents of
!applications.

This could be further enhanced by a command syntax that says:
show dirmenu entries, (except) or (only matching) <wildcardpattern>

Does this make sense?

Thus one could filter through for example .....!app.!Help or .....!app.docs

By changing the variable, it could be used as a find feature to make a menu
list files matching a template or wildcard.

Grant Randall grant_randall__ntlworld_com

--

What about TreePick?
What about a more advanced BASIC menu filter?

--------------------------------------------------------------------------------
DirectorWindow:
Ideas
=====

Use y as a validation string marker

have sub command,

1 - adjust
2 - menu
4 - select
 + combinations?

Including drags? Or no need of sub-command just run the command setting
Director$Window and Director$Icon as normal.

For drag messages (to and from) we need a different BUTTON type, so we
should change horses here and use the button type to switch instead of the
icon type. Have button types of dragto and dragfrom and return the path in
Director$File etc.

Make a note of technique used by save icon.

blah;y7menu:blob;y1

Validation type for send a message when the pointer goes over it (so you can
make menu-like objects).

Provide a method of making a window with a unique name? Or is this
equivalent to -temp - probably. -temp will make the windows referable only
by their handle.

Should return the name of the window in a system variable too I think.

Have a -nulls_if_closed (-background and -callevery <num>)
Have an event mask for open, close, null, dragto, dragfrom etc ?
Have an -invisible for the keys window?

Keep track of whether the window is open or closed

Make SWIs Director_SetIconText, windowname/handle, icon_name/handle, text
Director_GetIconText
SetIconVText
GetIconVText
Director_SetIconPath? - for save icon setting - or do we do it all ourselves?

Why do we need name? We can't set an icon up on initial opening, we have to
do it on the open call which is irritating - no real way round this because
we can't create the window before that - or can we if we start a task and
then send a registered message to director.

Make save, info, keys into completely dynamic windows - take them out of
director. Can then make them multiply instantiable and effectively make
Save: into a dynamic menu!

Make info message show thanks to every seconds or so!

Director should still deal with dragging to a draggable icon? Or is this an
event we should pass to the window?

Should return keys?

--------------------------------------------------------------------------------
Complete implementation of DirectorURL
Report error if the URL cannot be opened.

Philip Ludlam philip__philipnet_com

--------------------------------------------------------------------------------
I would like to see a way of customising tree menus.
In particular so that the user can be sheltered from
!App directory contents. However exceptions may be
useful like ...!App.!Help where it would be nice to
have !Help have a 'i' help icon.

Perhaps this could be achieved with a syntax
something like:

Treemenu <pathname> -apps -exceptions: "!Help","!"*,*"fred"*

where * are wild cards. Note I am not a programmer so
please forgive my description.

This has been my only misgiving in directors features.
I use !Director on my mentally handicapped brothers
computer and have to use other ways to provide
application treemenus.

--------------------------------------------------------------------------------
Dear All,

Several people have in the past mentioned to me that the existing
MenuMenu file is limiting with respect to extending:
  1) the filetype it handles.
  2) the range of options available for each type.

At the minute whenever a MenuMenu is done Director calls the
program/file referenced in <Director$MenuMenu>.
By default it is set to: Dynamic:/Director:Menus.Files.MenuMenu
Do people change this variable, or can/should the MenuMenu program/file
be hard wired into Director?

Comments please.

If:
!Director.Menus.Files.MenuMenu was a directory
Inside it was a !Run file (and/or a MenuMenu file). This would manage
  the MenuMenu system
Along side !Run the would be a Parent directory. This would contain
  files which operated on the parent dir. of the file in question.
Along side !Run and Parent there would be a Common directory. This would
  contain files which operated on the file in question.
For every 'common'filetype:
  a directory like FFF or FEB
    or
  a directory like Text or Obey (my preferred idea).
  This would contain files which operated on the file in question as long
  as it matched the filetype name of directory.

Director should probably set all the File$Type... variables that are
defined in this section.

For instance, it would look something like this:

!Director.Menus.Files.MenuMenu
  |
  |-- !Run
  |
  |-- MenuMenu
  |
  |-- Parent
  |     |
  |     |-- SetCSD (f)
  |
  |-- Common
  |     |
  |     |-- DirectorEdit (f)
  |     |
  |     |-- FilerRun (f)
  |
  |-- Sprite
        |-- IconSprites (f)


Comments please.


In action:
All files/programs marked by (f) would have two main execution paths.
When creating the MenuMenu menu each filewould get called with an
  argument like '-option' (preferred) or '-menumenu'.
In this case the file/program (script?) should call SWI
  "Director_Option" as many times as required.
It is up to the file/program (script?) to handle any subsequent calls to
  itself - as in it being called via a "Director_Option" or
  "Director_Command".

Comments please.

Any changes will be in the 0.30 release of Director - unless that is a
maintenance/bug fix release.

Yet again:
If you don't argue any of this with me then I'll do what I want.
Which may not be what *you* want.


Yours,

Phil L.

==

From: Matthew Somerville matthew_somerville__trinity_oxford_ac.uk

> At the minute whenever a MenuMenu is done Director calls the
> program/file referenced in <Director$MenuMenu>.

I wouldn't ever think of changing the reference, and think it should be
hardwired into Director. I would do as you suggest and make the MenuMenu
use external files that we could add to if we wanted. Easier for people
who don't know BASIC; they could just rustle up an Obey file or two if
need be.

> If: !Director.Menus.Files.MenuMenu was a directory

[snip]

As long as this doesn't slow it down running all these files, sounds
good. Though maybe having the option of having a single file for a
filetype, as well as a directory, for those filetypes that won't have
many options, or will have options that will only ever call external
programs and stuff like that. I personally would be happy with one
file/script for Obey files, one for sprite files, &c., doing all the
respective menu items (as looking at the current MenuMenu I don't see a
need for them to have a whole directory of files), then I could add one
for MP3 files or whatever.

==

My reply:

>As long as this doesn't slow it down running all these files, sounds
>good.

Good point.
I'll bear this in mind when I try out the idea.

********************************************************************************
     Though maybe having the option of having a single file for a filetype,
     as well as a directory
********************************************************************************

The limitation with the one file approach is: What if someone wants to
add an item?
This wouldn't be a problem until the user came to upgrade their copy of
Director and then they may lose their settings or not benefit from any
additions.
That said you do raise a good point so I will keep that in mind.

==

From: Jeff Haskell jeff__toy-town_demon_co_uk

Not hard wired, please, either a <Director$MenuMenu> so it can be altered
(that's the good bit about !Director it *can* be altered)

Or the bit about a 'Menu' directory as below sounds interesting

And could be used in other parts of director for more complex menus
(just a thought)

==

From: Lenny lenny__argonet_co_uk

> >> If: !Director.Menus.Files.MenuMenu was a directory

I like this idea. Configurable and extendable.

> The limitation with the one file approach is: What if someone wants to
> add an item?

This may be overkill, though how about ...

Duplicating this MenuMenu directory structure in Choices:Director.Menus,
so that any files placed in there (by the user) will be run in preference
to a file of the same name in !Director.Menus.

This way any mods made by users (in Choices...) will be safely retained
during any upgrade to the program.

--------------------------------------------------------------------------------
in !Core (and other menus) do an IfThereIs on '-path's and '-sub's etc. If
they don't exist - then don't add the menu option

Alan Birtles Alan_Birtles__ukgateway_net

--------------------------------------------------------------------------------
In !Core menus - a blank icon is displayed if the likes of sm!system and
sm!scrap aren't present.

Can we check this before generating the menu and do something about it?

Alan Birtles Alan_Birtles__ukgateway_net

--------------------------------------------------------------------------------
Do Bin as a Plug-in into Director

--------------------------------------------------------------------------------
Update/uprate the BASIC dynamic menu generators:

Check first - but add short GPL statement

Add a common set of headers to each giving, a title, purpose, syntax and any
recommended ways of calling it.

Set the minimum WIMP version (if needed) to 310. No point being any lower than
Director's minimum.

Make prominent use of functions
esp: for loops: returning and making use of the SWI number of a SWI
(it is faster this way).

Write this into 3rdParty.PLudlam.Templates

--------------------------------------------------------------------------------
The SaveBox is not like a true SaveBox it is more like a miniature Filer
window (except you can't (yet) double click on the icon).

Nick Craig-Wood? (from !Commands file).

--------------------------------------------------------------------------------
Reduce the size of the AddRes executable.
Perhaps copy the relevant OSLib source code into Director and just link with
that?
Are there any legal issues with that?

--------------------------------------------------------------------------------
I'm using an early beta of Director, and all text strings seem to be still
hardcoded into the main director module. I suggest they be taken out to a
proper Messages and Templates files, possibly gathered into an UK folder
inside !Director. This would help the internationalisation process, and also
would not break the consistency of my desktop (english director alongside
french risc os).

Jrme Mathevet jerome_mathevet__free_fr

--------------------------------------------------------------------------------

Other minor suggestion: could the clock under the director icon be set to
display HH:MM:SS by default rather than HH:MM ? I like to know how much the
machine is hung when I start various tasks (call that a basic stopwatch :).

Jrme Mathevet jerome_mathevet__free_fr

--------------------------------------------------------------------------------
Also, is there a file somewhere explaining all the default possibilities of
Director ? From the moment I adopted the program, it's always been trial and
error, and I would like things to change !

Jrme Mathevet jerome_mathevet__free_fr

--------------------------------------------------------------------------------
Reorganise to make more efficient use of allocated memory !Director.h.WorkSpace

--------------------------------------------------------------------------------
Provide a Director C header and ASM header file for OSLib.

Initially, only do definitions for variables

--------------------------------------------------------------------------------
Combine the open/closed status of windows with the torn off or not status.

--------------------------------------------------------------------------------
Sort out a 'noremove' option for windows. Put it on the Info window

--------------------------------------------------------------------------------
Ensure that all Director related (and set) variables all start with 'Director$'

--------------------------------------------------------------------------------
Re new MenuMenu:
>Talking of MenuMenus...   I don't have anything against the idea of
>having this implemented as a whole lot of separate files, but I don't
>see why the same can't be achieved via BASIC subroutines, making for a
>tidier implementation and wasting less disc space :-)   The contents of
>the MenuMenu needs a little tweaking either way.
>
>For the File menu I'd sooner have the Delete/Set Type options on the top
>menu than EditOutput/Filer_Run (the latter of which can be performed by
>clicking on the file icon at the top of the menu, can't it?)   This is
>because I never use either of them, of course.   But again, I'll just
>hack my personal copy, or more likely go back to the old implementation.
>
>Several options seem to be applied to an object's parent directory,
>when if you clicked upon the object you are far more likely to want to
>apply them to the object itself - AddTinyDir and Pin, for example.  The
>only useful applications you want to perform on the parent directory of
>the object you have selected (bearing in mind that you may have navigated
>through several layers of upmenus to reach it - this is after all the
>basic point of the Director interface) is to open its parent or make it
>the CSD.   If you want to do anything else to the parent, then you can
>just use the upmenu.   It's slightly more trouble, but not half so much
>as being unable to apply certain functions to files at all!
>
>(And why is Command grouped in the 'top' section with the parent
>directory functions when experiment proves it to act on the file?)

--------------------------------------------------------------------------------
In message 4b3bb354b5lenny__argonet_co_uk
          Lenny lenny__argonet_co_uk wrote:

>In file '!Director.Menus.AutoRun.!Core', menu 'Backdrop' :
>
>  The last line (TreePick Others...) refers to a user absolute filepath
>  (Root:Oddments.Backdrops)

I'm not sure where Root:Oddments.Backdrops came from. I don't remember
putting it in so I think it must be something Nick put in.

>  Wouldn't it be better to use a sys var (eg Director$Backdrops) which
>  could be defined in 'Choices:Director.Menus.AutoRun.!!SetVars' ?
Could be...

>   Also this line benefits from a Command option :
>    Command Filer_OpenDir <Director$Backdrops> -sn -si
>
>Similarly on all points for the menu 'Tools' (use a var
>Director$ToolSprites).
>
>In each case, if the var is undefined, the menu item could be omitted.

Similarly the Palette menu and WimpSprites could also work like this.

For WimpSprites, ToolSprites, Backdrops and Palette, what about looking
in the directories:
  Choices:[type]
  Root:Oddments.[type]
Expanding <Director$[type]> and listing those directories (or files).
And rationalising the rest of options that already exist.

--------------------------------------------------------------------------------
Look at Task and how it initialses its internal variable area.
Implement that in other files as required.

--------------------------------------------------------------------------------
DirectorCanon
DirectorCanonicalise

--------------------------------------------------------------------------------
DirectorOption

1) Do something about wimpslot of commands being run?
Integrate this with DirectorOptions.

2) AW Horsley:
> Is there a way of Director ensuring on startup that the computer knows the
> paths to a specified set of applications and has their sprites loaded?

However I did think that Director could have an option to Filer_Boot any
applications you place in any menu it loads on start up which might be more
what you are thinking.

3) Canoncialse filenames

4) Memoriser MenuMenu-ed files

5) Move mouse pointer when opening OldMenu

6) Show any initial ! in filenames.


Look into making the Filer menu (in AutoRun.Filemenu) into a dynamic menu.
Move all file specific stuff out of !Core and into Filemenu.

--------------------------------------------------------------------------------
>Suggestion/Queerie for directory menus
>
> Unsure if this can be done or is implimented already ...
>
> Directory menus (menu click on a Filer title bar) can create some
> very large menus, could these have some options on sorting
> 'large directory menus'
>
>   eg directorys only, files only, ...
Or an applications only (just like you can with memoriser)

> ... sort by size, name, date, etc

Fine ideas here Jim, however implementing then (and sorting out how it
will all be configured) will take time.

What happens is that Director creates the menu (with just the filenames
in it) based on what the OS says there is in the directory. This isn't
always sorted alphabetically due to programs like LongFiles and other
things(*) so Director then sorts the menu.

As to implementation: It looks like a partial re-write of directory menu
routine. And there are also other suggestions for directory menus which
would make sense to incorporate at the same time.

But configuration. Are there any suggestions?

(*) FWIW: LanMan98 doesn't sort directories with more that 256(ish) entries.

From: Jeff Haskell jeff__toy-town_demon_co_uk

--

What about allow Path: to have options, so that it becomes:
  Path:<path> [-sn|-SortName|-st|SortType|-ss|SortSize|-sd|SortDate]
    [-r|Reverse] [-up] [-type <n>]

  Where:
    [-type <n>]
           1 = shows applications,
           2 = shows directories and images,
           4 = shows files
      The parameters can be combined in a linear fashion, eg 6 shows
      directories, images and applications but not files. - just like Memoriser:
      The default is 7 (show all).

--------------------------------------------------------------------------------
Lenny:

> * In the TreePickSM generated menus, it would be nice if SHIFT-selecting
>   an entry that is a dir would Filer_Open that dir, rather than opening
>   the submenu (as currently, with or without SHIFT).

I've made a note of that.

--------------------------------------------------------------------------------
From: John Pettigrew john__NOT-RELEVANT_headstrong-games_co_uk_INVALID>

> You don't need to run Close (unless it offers more features than what
> Director has, and in that case I'll see what I can do about putting
> them into Director :-) ).

Close lists the open files by type, and lets you close them by simply
clicking on them in the list. Quite nice, because it separates the actual
open files  from e.g. font files, run files, obey files, archives etc. that
can clog up a simple list of open files.

--------------------------------------------------------------------------------

Expand the SWI module to have another command: UserMessage
It calls Wimp_SendMessage with the parameters it is given.
Eg:
UserMessage &400D1 1 0 0 0

Note: The user must be sure about what they are doing. Strings will not be
referenced, but copied directly into the SendMessage block. It will send
messages with Poll code 17.

--------------------------------------------------------------------------------

>I'm wondering how possible it would be to use Director to increase the
>keyboard navigability of RISC OS for example, specific keys to close windows
>(much like Windows), keys to open menus and then the up and down arrows to
>move the pointer by x to select options.
>
>I've not given it any more than 30sec thought so it may not be possible at
>all.

Jon Wright jon__textor_com

At the moment it is possible to assign keys to open menus or to carry
out commands.
i.e.:
  Menu "DDE" -key ^D
and
  Option "Modes" -sub * -key M
for instance.

It shouldn't be too hard to extend Director to offer the same
functionality to it's windows.

I'm not sure about moving the cursor though.

--

DirectorKey name <action> -key <key> [-remove]

when <key> sequence is delected run the *-command <action>

So that you could have:

*DirectorKey "Window Mey Key Menu" "simclick -menu" -ley WinMenu

which opens up a context sensitive menu (presuming you can have one!)

*DirectorKey "Pinboard to top" "Message &400D1 1 0 0 0" -key ^PgUp
*DirectorKey "Pinboard to bottom" "Message &400D1 2 0 0 0" -key ^PgDown

StrongED also uses Message in a script to open all it's source files.
Where did message come from?

--------------------------------------------------------------------------------

Add FNmodule_version to resources
Add ModuleVer to Utils
Add FNcommand to resources
Add make/amu stuff to MakeFiles (from MakeFilesN)
Add cvs submenu (if there is a CVS sub-dir in the directory) t
update/commit/add/diff etc. for files and directories


--------------------------------------------------------------------------------

ALib2:
SetV ClearV etc macros:
just do exactly what they say, any other affect of them cannot be relied upon.

Expand the ChangeFlags macro:
add suport for stacking and unstacking the temp reg - incase reg's are running out.

create SetVClearCNZ style macros which utilise ChangeFlags macro
--------------------------------------------------------------------------------

Is it possible to use a sys var dynamically in a menu title ?  Ie I'd
like to use C$Mode in the DDE menu title.  However, a simple :
  Menu "DDE (<C$Mode> bit)" "DDE"
is static (ie whatever the var was at the time Director was loaded).

Lenny
--------------------------------------------------------------------------------

>It's weird when the filer opens a dir with a '^' in the path, as when you
>go up a directory (Open parent, or whatever) you end up going down a
>directory !  You can also end up with 2 filer windows for the same dir.

When Director tells the filer to open a directory/file/application it
should canonicalise the file name (from a directory menu / menumenu /
memoriser / option "" -path "").
But it maybe the case that the support program doesn't do that. If
there is a case where it doesn't then please let me know and I'll do
what I can to fix it.

Note: Check all support progs. May as well make this universal across all of
Director

Lenny
--------------------------------------------------------------------------------

can we find out what commands are supplied by modules and add support for
that to IfCommand?
--------------------------------------------------------------------------------

In line with MenuMenu properly supporting image files:

 also a 'check MD5' of iso images from the menu menu system yet
 it always sees them as directorys ?

From: Jeff Haskell <jeff__toy-town_demon_co_uk>

--------------------------------------------------------------------------------

Enhanced info on Files
Can the File info window (off of the Filer window) show more info on the file
if appropriate.
i.e.g MP3s could show author/title info.
images their size & resolution
etc.

Should this also be off of the MenuMenu menu?

--------------------------------------------------------------------------------

Add "Info ->" option to the main CDFS menu (just like in Select).
--------------------------------------------------------------------------------

Here's one for the real niceties :-) :
  If a Filer window is open on screen when generating a directory menu, give
  it a open-directory sprites rather than the normal closed one.
--------------------------------------------------------------------------------

Incorporate suggestions at: http://www.iyonix.co.uk/32bit/help.shtml
--------------------------------------------------------------------------------
Malcolm Boura <malcolm__armage_demon_co_uk>:

The browser Oregano, and no doubt others, may have a URL such as

file:ADFS::hardDisc4/$/fred/page.html

in the title bar. It would be nice if director understood them. It would
be even better if OS_FSControl 37 understood them.

Phil said:
This only seems to be the case in Oregano.

As an aside: it maybe the case that, for certain tasks/conditions an external
utility is run which, given the titlebar text, generates a suitable menu for
Director to display?

--------------------------------------------------------------------------------
From: Grant Randall- Spam trapped grant_randall__ntlworld_com

Philip Ludlam news__philipnet_com wrote:
> Dear All,

> This is to announce the 0.36 stable release of Director.

Is there yet a way of disabling global tree menus (adjust click on drives
etc).
I do however find them useful sometimes.


Phil:
How?

Grant:
See also:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=4826b8c8f3grantr%40argonet.co.uk&rnum=1&prev=/groups%3Fq%3Dgroup:comp.sys.acorn.*%2Bdirector%2Btree%2Bmenu%2Brandall%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D4826b8c8f3grantr%2540argonet.co.uk%26rnum%3D1

John Sandford sandford1__ntlworld_com:
I also endorse the above changes, except with the adjust drive menus
could this feature be removed from always being on all drive icons;
which would allow anybody to set a filter to do this selectively by
filing system.


John Sandford sandford1__ntlworld_com wrote:

>Philip Ludlam news__philipnet_com wrote:

[snip]

>> So what about:
>>   *DirectorOptions -filerfilterkeys "<key modifiers like alt or shift or
>>   ctrl all separated by spaces and enclosed with in speech marks>"
>> (correcting a possible misunderstanding with what I previously wrote)
>>
>> and:
>>   *DirectorOptions -filerfilterfilers "<list of filer modules/tasks
>>   without the Filer bit in their name i.e. 'SCSI' and 'IDEFS' all
>>   separated by spaces and enclosed in quotes>"
>> ?
>>
>> Note that -filerfilterkeys is for what keys are pressed in combination
>> with adjust click to generate the menu and that -filerfilterfilers is
>> for what Filer tasks to generate the menu.
>
>I would be happy for the adjust key menu to work without key modifiers
>and using the -filerfilterfilers to control on which filesystems the
>menu is present.

The default currently is no key modifiers and all filers. This default
will be maintained through whatever extensions I make to FilerFilters.

>> Or do you want finer controll over the drive icons? Do you want to
>> specify them like ADFS::4 and/or IDEFS::Gromit as well as CDFS (for
>> all CDFS icons)?
>
>This would be my preferred way.

Thought it might be :-)

>What I had in mind in my last posting is that the current adjust click
>menu can be, globally switched off/removed completely

If you want to switch off the feature altogether:
  *DirectorOptions -filerfilterfilers " "

--------------------------------------------------------------------------------
